Internet-related networks (e.g., the World Wide Web (Web)) may be used for application broadcast and sharing conferences. An application broadcast and sharing conference may consist, for example, of a conference moderator who may have a particular application (user-oriented, specific-function software) running on a digital processing system (DPS). The conference moderator may wish one or more conference participants, located at remote digital processing systems, to be aware of the moderator's interaction in regard to the application. Potentially, sharing an application may extend to allowing one or more participants to take control of the application from the moderator. Such application broadcast and sharing, via the Web, has increased dramatically in recent years.
Typically, application broadcast and sharing is accomplished by making the pixel data from the moderator's DPS available on a server DPS which transmits this data through the Internet to remotely locate participant (client) DPSs. The participant DPSs receives the data and causes the corresponding images to be displayed for the participant at the participant's DPS. Typically, the participant DPS is executing a streaming media playback software, such as Real Player from RealNetworks Inc. of Seattle, Wash. Streaming allows the data to be processed as a steady stream in real time. The presentation from the moderator's DPS is transmitted to the server on an on-going basis. For example, the system may periodically conduct a screen scrape. A screen scrape may be conducted by performing an exclusive OR (XOR) operation between the pixel data from the current screen and the pixel data from the last screen sent to the server. This XOR operation causes all the pixels that have not changed since the last screen scrape to become blackened, and the rest colored. The server keeps a queue of the screen scrapes, which is a history of what has changed on the moderator's DPS. To reduce the amount of data that must be stored on the server, the screen scrapes are compressed. For example, a run-length encoding (RLE) compression scheme may be used to compress the data. RLE compression provides a high rate of compression for situations such as this where there are large runs of identical values. The runs are compressed to the value, and a number indicating the length of its run.
The participant DPSs download data from the queue as fast as they are able based on the connection and processing capabilities (speeds) of the individual participant DPS. The streaming provides an animation effect, but may allow some participants to fall behind the rest of the conference if their connection and processing speeds are not adequate. Such systems take into account that the Internet is not an ideal medium for real time communication and therefore add buffering which helps to provide a coherent display. This buffering adds a delay of several seconds. Moreover, some current systems queue and create image buffers on a per user basis so that as more participants join a conference, it becomes more difficult for the server to manage the outgoing stream. That is, as the number of participant DPSs is increased, the hardware requirements for a given server DPS may become too great, requiring distribution through streamsplitting. Such systems may split the data stream among several servers to distribute the load to effect scalability. Each streamsplit adds latency to the system reducing the real time affect.
Such methods are inadequate for real time conferences in which a telephone system may be employed to describe the application. That is, as the moderator is describing the application over a telephone system, the participants should be viewing those aspects of the application to which the moderator is referring. Delays caused by buffering or scalability factors (e.g., streamsplitting) have a disconcerting effect upon the conference.